An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hello everyone, My app is has been "In Review" since Thursday evening, and held in that status since. In my experience, when an app moves to "In Review" it takes at most an hour to review app functionality and move to ready for release. We have timelines to meet. Neither an expedited review nor reaching out to support helps the situation.

Hi all, I’m looking for some guidance regarding my app review status. About a week ago, I submitted my app for review on the App Store. The review team responded asking for some declarations and a few changes in the app. I addressed all the requested changes and resubmitted the app promptly. However, it has now been more than a week since the resubmission, and I haven’t received any further updates or feedback from the review team. The status still appears unchanged, and there has been no communication. I understand that review times can vary, but I wanted to check: Is this delay normal after a resubmission? Is there anything I should do from my side (e.g., follow-up, resubmit again, contact support)? Has anyone else experienced similar delays recently? my app name is Darenite Any insights or suggestions would be really helpful. Thanks in advance!

My app is stuck in the "in review" stage for over 3days. . Did my review get stuck or lost or something? Is there anyway to get any clarity on this?

Dear App Review Team, Our app – Apple ID 6757288398 has been stuck in the “In Review” status for over 3 daysNormally, reviews ends typically in 48 hours(i requested expedite review) it seems unusually delayed. Could you please clarify: • Is there a specific reason for this extended hold? • Is any action required from our side? • When can we expect the review to proceed? Thank you very much for your time and assistance.

Hello, I submitted an update for my app for review on April 27th. Since then, the app has remained in the “Waiting for Review” status. I contacted support by email after one week and again after two weeks, but both of my messages were left unanswered. Please provide me with an overview of what is going on with my app submission for review. Thank you.

Hello, I'm hoping someone from the App Review team can look into this situation, which has specific context that I believe makes it worth a careful look. Thank you in advance for your time. I'm hoping someone from the App Review team can look into this situation, which I believe has specific context that makes it worth a careful look. My app YADA: You've Already Met (App ID: 6759586097) has been in "Waiting for Review" since Wednesday May 6 at 7:44 PM ET - now over 96 hours. I have an open support case (20000112508151) filed Friday with no response yet. I'm not writing simply to flag the wait - I want to explain why this submission deserves a thoughtful second look on the merits. When YADA was submitted for TestFlight beta review, it was flagged under Guideline 4.3(b) for the same reason as the App Store rejection. I appealed, explained the differentiating mechanic, and an Apple reviewer evaluated the argument and approved the app for external testing. That approval is on record. I'm asking for consistency with that prior decision. YADA's core mechanic is genuinely unlike any dating app currently on the App Store. A user privately adds someone they already know to a list. That person receives no information about who added them. A match is only revealed when both people have independently and privately added each other. If the feeling isn't mutual, nothing is ever disclosed. There is no browsing of strangers, no algorithmic recommendations, no swiping, and no rejection possible because neither party knows they've been added until both have added each other simultaneously. Critically, YADA does not ask users to declare their gender or sexual preferences - because the mechanic doesn't require it. This makes YADA the only interest-discovery platform on the App Store that works entirely without those declarations, which creates a uniquely safe experience for LGBTQ+ users and young people who are not ready to publicly disclose their orientation. No equivalent experience exists on the App Store. The App Store rejection also included 5.1.1 and 2.1 issues, both of which I fully resolved - redesigning the contacts permission flow with a proper in-app explanation screen and directly answering Apple's question about data handling - with a new build submitted alongside my Resolution Center reply. I'm not asking for special treatment. I'm asking for the opportunity to have the full argument evaluated by a reviewer with the time to consider it, consistent with how the TestFlight review was handled. Support case: 20000112508151. App ID: 6759586097. Submission ID: abdf8b5b-5ea0-46a4-8a0b-fb58320fa701. Thank You

We have been waiting for the App Review process to complete for almost 2 weeks already. The review process appears to be completely stalled.

We submitted an app update to App Store Connect and it finished processing. We have since discovered and fixed an additional bug, and will need to resubmit the binary. The processed version wasn't sent it for review (only processed), so need to know if we can still keep both the same version and build number?

Hello, I am developing an macOS app and planning to implement a cross-platform save feature. I have two questions regarding the App Store Review Guidelines and Game Center integration. 1. Requiring Game Center exclusively for an optional "Cross-Save" feature (Guideline 5.1.1 & HIG) in macOS To comply with Guideline 5.1.1(v), we do not force users to sign in to Game Center upon app launch. Users can fully access the core features, play locally, and even use standard iCloud sync without any Game Center authentication. However, to use the specific, optional "Cross-Save" feature (which syncs data across different platforms via our proprietary backend), we intend to require Game Center login. Question: Is it acceptable to prompt for and require Game Center authentication only when the user explicitly tries to enable this specific cross-save feature? 2. Associating Game Center IDs with a proprietary backend account (Guidelines 4.5.3 & 4.5.5) To facilitate cross-progression, our backend server plans to authenticate the user using Game Center's identity verification signature via fetchItems(forIdentityVerificationSignature:). Once authenticated, we want to link the user's Game Center ID (specifically, teamPlayerID or gamePlayerID) to our proprietary service account in our own database. Question: Guidelines 4.5.3 and 4.5.5 state that we should not share Player IDs with "any third party." Does storing and linking the Game Center ID to our own backend server account (strictly to manage our game's cross-saves) fall under this "third party" restriction, or is our proprietary backend considered a permitted, first-party use? I want to ensure our implementation fully complies with Apple's privacy and user experience standards. Any insights would be greatly appreciated. Thank you.

Hello, I would like to check the status of my app, as it has been stuck in "waiting for review" for almost a month (ID: 6746933136). Thank you

Hello, I would like to check the status of my app, as it has been stuck in review for a while (ID: 6746933136). Thank you

Dear App Review Team, I am writing to escalate an ongoing and critical issue regarding our app review. App ID: 6705133649 Status: Waiting for Review since April 30, 2026 — now over 10 days with no progress. Timeline of events: • April 30 – Submitted for review • ~May 4 – Posted on Apple Developer Forums requesting an update • May 5 – Apple responded: "We're investigating and will contact you in App Store Connect" • May 9 – Followed up again after no contact was made • Today – Still no review, no contact, no explanation We have received no communication via App Store Connect as promised. This is part of a larger pattern we have experienced: • Our reviews previously completed within 48 hours consistently • Our last review cycle took approximately 1.5 months • This current review is now past 10 days with no movement We are formally requesting: Immediate escalation to a senior App Review team member A clear explanation of why this review has stalled Confirmation of whether any action is required from our side A committed timeline for resolution This delay is directly impacting our users and business. We are fully available to provide any additional information, demo credentials, or clarification needed — and will respond immediately to any request. We respectfully ask that this be treated as urgent and resolved within 48 hours. Thank you.

Hello, I am posting regarding my app, Apple ID 6755677576. My app was rejected on April 2, and I resubmitted it. After several weeks without any progress, I had to cancel the submission because the delay had become highly abnormal. I resubmitted the app again on April 23, and it is still stuck in “Waiting for Review.” This situation is critical because the live version of the app has contained a severe blocking bug since January 23. Due to these unusually long App Review delays, I have been unable to release the fix, and users continue to leave negative reviews because the app remains broken. In addition, for months, TestFlight builds have also remained pending review for unusually long periods. This means I no longer have any practical way to provide affected users with a corrected version while waiting for App Review, even though they are actively complaining about the blocking bug in the live version. I would like to know whether other developers are currently experiencing similarly unusual delays for both App Store review and TestFlight review. Thank you.

Dear App Review Team, Our app – Apple ID 6755677576 has been stuck in the “In review” status for over 10 days (since March 17, 2026). Normally, reviews begin within a few days, but in our case, it seems unusually delayed. Could you please clarify: • Is there a specific reason for this extended hold? • Is any action required from our side? • When can we expect the review to proceed? Thank you very much for your time and assistance.

Hello Everyone, For the second time in 3 months, I am seeing my app getting stuck in 'Waiting for review' state for weeks. I wrote to apple support and got an email 11 days ago saying they have initiated expedited review of the version review. But still I see no progress with the review and status is still waiting for review. I sent emails 2-3 times after that but no response. Did anyone else face this and what else can I do now? Thanks

I've been stuck on Guideline 2.3 for two weeks now and I'm running out of ideas. My app is iPhone-only (UIDeviceFamily = [1]) and has been on the App Store since January. Version 2.1.9 passed review fine. The only change in 2.1.10 is adding two DeviceActivity extensions — a DeviceActivityMonitor and a DeviceActivityReport — for screen time-based stress detection. Every build since then gets rejected with the same message: "The UIRequiredDeviceCapabilities key in the Info.plist is set up in such a way that the app will not install on the device used in review." Review devices: iPhone 14 Pro, iPhone 17 Pro Max, iPad Air M3. Here's what I've tried across 13+ submissions: UIRequiredDeviceCapabilities as ["arm64"] (array) — rejected Empty array [] — rejected Removed the key entirely — upload validation fails, Xcode re-injects arm64 anyway Post-build script to force ["arm64"] — rejected Dictionary format {"arm64": true} — rejected Added com.apple.developer.family-controls to extension entitlements — rejected Enabled Family Controls (Distribution) on extension bundle IDs — rejected Fixed CFBundleVersion mismatch between host app and extensions — rejected Set TARGETED_DEVICE_FAMILY=1 on all targets including extensions — rejected Tried GENERATE_INFOPLIST_FILE=YES with minimal plists — rejected Tried ExtensionKit type for the report extension — rejected In the exported IPA, every target has UIRequiredDeviceCapabilities = ["arm64"] and UIDeviceFamily = [1]. The entitlements, provisioning profiles, and code signing all look correct. arm64 is supported on every review device they listed. The previous version (2.1.9) without DeviceActivity extensions passes review with the exact same UIRequiredDeviceCapabilities and signing configuration. Has anyone shipped an app with DeviceActivityMonitor + DeviceActivityReport extensions successfully? Is there something specific about these extension types that affects device capability validation? Or is there a known issue with the review system and FamilyControls extensions? I've replied to the review team multiple times asking which specific capability is causing the failure, but the response is always the same generic template. Any guidance would be really appreciated — I'm completely blocked on shipping this update.

I’m running into an App Store Connect issue and I’m trying to figure out whether this is a build configuration problem on my side or a backend issue in App Store Connect. When I try to save my app version after selecting a build, App Store Connect fails and DevTools shows this request failing: PATCH /iris/v1/appStoreVersions/ with a 409 Conflict. The response body is: Json { "errors": [ { "id": "af484f56-8f7d-4338-a04a-2aeda858ace1", "status": "409", "code": "ENTITY_ERROR.RELATIONSHIP.INVALID", "title": "The provided entity includes a relationship with an invalid value", "detail": "The specified pre-release build could not be added.", "source": { "pointer": "/data/relationships/build" } } ] } A few details: The issue seems to happen with all uploaded builds, not just one The builds finish uploading and appear in App Store Connect I’ve already checked and corrected my version/build number setup I created a fresh Release archive I uploaded a new build I removed the previously attached build and tried attaching the new one App Store Connect still refuses to save the version once a build is selected I’ve already verified that the app version and build number in the project appear to be set correctly. At this point I’m trying to understand: Any suggestions on specific things to check would be appreciated. Thanks.

I’m looking for guidance regarding App Review classifying my app as gambling / real-money gaming under Guideline 5.3.4. My app is a free football prediction competition app where users predict match scores and compete in rankings based on prediction accuracy. Top-ranked users may occasionally receive promotional physical prizes such as headphones, consoles, or other products. Important details: participation is completely free there are no entry fees users cannot deposit money users cannot withdraw money there is no wagering or betting system there are no sportsbooks, odds, or casino mechanics users never risk money to participate prizes are funded directly by the platform as promotional rewards Apple rejected the app under: Guideline 2.3.6 – Accurate Metadata Guideline 5.3.4 – Gaming, Gambling, and Lotteries App Review is stating that the app includes “real money gambling, real money betting, or real money skill-based gaming” and is requesting gambling licenses and geo-restrictions. My understanding was that gambling generally requires users to risk something of value (money/payment/consideration) for a chance to win prizes, which does not happen in this app. I would appreciate guidance from developers who have experience with: Free prediction or fantasy-style apps with promotional prizes Skill-based competitions reviewed by Apple Sweepstakes/contest compliance on the App Store UI/wording that may accidentally trigger gambling classification Whether App Review typically requires legal contest rules instead of gambling licenses in cases like this If anyone has successfully published a similar app, I’d really appreciate hearing what changes or clarifications helped during review. I want to launch initially in Brazil Thank you.

Hello App review Team, Our app has been submitted for up to a week now. Submission id - 8b32ad4d-9912-4f25-837c-13b15323a258. Kindly review. Thank you

Hello, I'm posting again — and unfortunately, I already know how this thread is going to go. My app (ID: 6756186616) has now been stuck in "In Review" for 80 days. To save everyone time, here is the reply I expect to receive within a day or two, copy-pasted from the response on my last thread: "Thank you for your post. We're investigating and The App Review team will contact you in App Store Connect to provide further assistance. If you continue to experience issues during review, please contact us." Nothing actually happened after that reply last time. No follow-up in App Store Connect. No further communication. Just silence. When I escalated to Developer Support (case #20000111565861), I was told explicitly that Developer Support has no way to reach the App Review team and no authority to intervene on submissions stuck in review. So Developer Support points back to App Review, and the standard forum reply points back to "contact us" — which loops back to Developer Support. This is a closed loop that doesn't actually resolve anything for an independent developer. Concrete questions: Is there any real escalation path that doesn't end in an automated reply? Why has a submission been "In Review" for 80 days with zero communication? What should a solo developer do when both Developer Support and the forum response are dead ends? I'm not asking for special treatment. I'm asking for the review to actually move — in either direction. A rejection with feedback would be infinitely more useful than 80 days of silence. Thank you.